Cloud-computing environments and enterprise networks may comprise many software applications and utilities that each requires an independent identification or authentication procedure, such as entering a username and password or identifying a security image. Higher-security applications that automatically log out inactive users may force a user to sign on and authenticate several times a day.
A Single Sign-On (SSO) function can simplify these requirements by allowing an Identity Provider (IDP) to authenticate a user and then forward user-authentication information to Service Providers within a single domain that would otherwise require an additional manual sign-on for each application, tool, software module, or other service accessed by the user. In this way, SSO may allow a user to access multiple services, without additional sign-on activity, after being authenticated a single time by the IDP.
SSO capabilities may further be “federated” in order to simplify user sign-on requirements where services are provided by a “federation” of different, and often unaffiliated, Service Providers across multiple domains. Federation for single sign-on is implemented with agreed-up interaction protocols, such as Security Assertion Markup Language (SAML), that allow for the exchange of user information, across domains based on federation-brokered trust relationships. Federated identity management allows multiple, unaffiliated IDPs to quickly respond to a Service Provider's request for to authenticate users requesting access to a service or set of services offered by the Service Provider. Similarly, federated identity management allows multiple, unaffiliated Service Providers to provide services to users associated with an Identity Provider without requiring the users to re-authenticate at each Service Provider.
Such implementations are especially effective when Service Providers, despite each maintaining a trusted relationship with a single Identity Provider, cannot directly share confidential user data across the set of Service Providers because the Service Providers themselves are not in trusted relationships with each other.
Federated SSO (F-SSO) capabilities can be expensive and complex to implement as it requires changes to a Service Provider's user authentication process. These changes are often cost-effective in environments where initial implementation costs can be spread across a larger number of users. In cases where the number of users who require F-SSO is a small percentage of the set of overall users who require access to an environment, or where the changes to the environment's native authentication process are too extensive, however, it may not be cost-effective for a Service Provider to offer F-SSO capabilities to users in that group.
One example of such an implementation might be an F-SSO federation in which a Service Provider is an Infrastructure as a Service (IaaS) provider and the class of F-SSO requiring users consists of a small number of system-management personnel representing a very small percentage of the overall set of users accessing the IaaS provider's resources. In such a case, it may not be practical to implement F-SSO for the system-management users given the costs of adding/changing the SP's environment to support F-SSO and the potential impact from a usability point of view on the remaining set of users, representing the majority of the SP's users.